-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-introduce concept of projection cache 'completion' #89831
Conversation
r? @wesleywiser (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 58de3037235c48765dcdfb6530cb316ac025ec5b with merge fa1210416b5caa99212b19d594ef3da8ae3132f1... |
☀️ Try build successful - checks-actions |
Queued fa1210416b5caa99212b19d594ef3da8ae3132f1 with parent 0446743, future comparison URL. |
Finished benchmarking commit (fa1210416b5caa99212b19d594ef3da8ae3132f1): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
@nayato: I'm glad to hear it! I came up with this as a fix for #89195, which appears to have the same underlying cause as your issue. Unfortunately, part of the issue with #89195 seems to be be the 'eager' evaluation and discarding logic that I added in #85868 (and that I've now removed from this PR). When there are a large number of projections with a large number of sub-obligations, this appears to blow up compilation time. Unfortunately, removing that logic appears to have a large negative impact on the |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 6971dea4036a802fe9d7a838b8d3e655fee7d70f with merge 38dc5847c0733779aaaa9e3de4408165ea7a2b05... |
Perf aside here, I would have extreme reservations about landing this PR without proper tests for the original incremental issues that required us to remove a lot of the caching code. |
☀️ Try build successful - checks-actions |
Queued 38dc5847c0733779aaaa9e3de4408165ea7a2b05 with parent 81117ff, future comparison URL. |
Finished benchmarking commit (38dc5847c0733779aaaa9e3de4408165ea7a2b05): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
6971dea
to
62e7bcd
Compare
☀️ Try build successful - checks-actions |
Queued 02aeffa72b11c0501c63a17d3e3f27c833ef2cbf with parent d3848cb, future comparison URL. |
Finished benchmarking commit (02aeffa72b11c0501c63a17d3e3f27c833ef2cbf): comparison url. Summary: This change led to small relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
Instead of clearing out the cache entirely, we store the intermediate evaluation result into the cache entry. This accomplishes several things: * We avoid the performance hit associated with re-evaluating the sub-obligations * We avoid causing issues with incremental compilation, since the final evaluation result is always the same * We avoid affecting other uses of the same `InferCtxt` which might care about 'side effects' from processing the sub-obligations (e,g. region constraints). Only code that is specifically aware of the new 'complete' code is affected
2517bd2
to
40ef1d3
Compare
@bors r=jackh726 |
📌 Commit 40ef1d3 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d6cffe4): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Any chance this can make it into 1.58? It fixes severe build times we have since 1.56 in a tonic/tower-based application of ours and essentially holding us back from upgrading to edition 2021 and a more recent rustls. |
I'll nominate this for stable and beta. Personally, I think is at least as risky as #90423, and that got stable declined. But a beta backport might be okay here. I'll nominate both for discussion. |
Discussed in T-compiler meeting. Deferring decision on whether to backport (any of beta/stable) until next week, at least. |
Discussed again today and the decision is to not baclport this on both beta or stable channels Zulip topic @rustbot label -beta-nominated -stable-nominated |
Instead of clearing out the cache entirely, we store
the intermediate evaluation result into the cache entry.
This accomplishes several things:
the sub-obligations
the final evaluation result is always the same
InferCtxt
whichmight care about 'side effects' from processing the sub-obligations
(e,g. region constraints). Only code that is specifically aware
of the new 'complete' code is affected
Authored to address issue #89195